Возникла у меня мысль соорудить pops, smtps, https с более серьезными правилами нежели по умолчанию.
Почитал на эту тему. Кое-что соорудил.
Создал Сертификат CA, новый сертификат сервера, и соответственно подписал с помощью CA.
Впихнул в клиента сертификат CA. Все вроде нормально. Yb Thunderbird ни Firefox более не жалуются на несоответствие сертификату. НО. Мне этого мало. Хочется вот чего:
- Что-бы сервер не принимал соединение, если клиент не предоставит еще и сертификат Клиента. Соответственно тоже подписанный моим CA.
- А в идеале было-бы весьма полезно, если-бы и аутентификация клиента производилась по Клиентскому сертификату. Я так понимаю,что п.1 — это даже не к ЕСерву вопрос, а к SSL. А именно к серверному сертификату. Это так или Есерв тут тоже задействуется? По п.2, как я понял, несколько сложнее т.к. в EServ не может использовать сертификат x509 как Источник аутентификации/авторизации. Я прав? Или все-же есть пути?
- Управляется опцией SslVerifyClient соответствующего сервера. 0= не проверять клиента, 1 = проверять, 2 = отказываться соединяться, если нет клиентского сертификата или издатель сертификата клиента неизвестен.
- Тут придётся добавить одну строчку в конфиг...
Список сертификатов CA, сертификаты изданные которыми сервер должен принимать в п.1, добавляются в server.pem (кроме своих CA-сертификатов я в тестах добавлял Verisign (они выдают бесплатные сертификаты для почты — "Class1 digital ID") и WebMoney (тогда он принимает те же сертификаты, которые используются для light.webmoney.ru)).Добавить её после строки "SSL_CLIENT 250 LOG" в OnStartup.rules.txt.
Понял. Мне, собственно, сейчас для E3 нужно. Ибо горит. А в дальнейшем для E4. т.к. он у нас также имеется. Но еще не введен в эксплуатацию. Кучу всякого надо из 3 в 4 переносить.
Потер из Firefox и Thunderbird все свои сертификаты. И клиентские и CA.
Зашел Firefox'ом на сайт. Ругнулся лис, что сертификат не доверенный. Я нажал Принять сертификат и вошел на сайт.
Аналогичная ситуация с acSMTP. Отправляешь письмо, Thunderbird просит принять сертификат и отправляет письмо.
ред: 11.11.2010 17:32
В порядке бреда — а если код 3 попробовать?
Верно, там в последнем поле будет информация из клиентского сертификата (если он был).
Да, надо попробовать. Там "1" = SSL_VERIFY_PEER, а "2" = "SSL_VERIFY_FAIL_IF_NO_PEER_CERT", их можно по OR объединять.
Для чистоты эксперимента начните вообще с "1". При подключении браузером должно выскочить окошко с запросом клиентского сертификата, а не с предложением принять серверный (если вы его уже принимали, или если устанавливали свой CA в доверенные, то браузер сам примет серверный сертификат без лишних запросов).
Не бред, а требование документации — "This flag must be used together with SSL_VERIFY_PEER".
Сейчас попробую 3.
ред: 11.11.2010 18:29
Значит, я правильную книжку читал
Только не помню, где. Наверное, на самом openssl.org.
ред: 11.11.2010 19:11
Кстати, а где можно глянуть описание кодов ошибок? На openSSL.org вроде не видно. С документацией там вообще что-то туго.
Добавил в FF CA и клиентский сертификаты. Пустил!
Потом удалил сертификат CA из Firefox. Снова свободно зашел на сервер. FireFox и слова не сказал. Только клиентский сертификат выбрать предложил. Это как-то настораживает. Как тогда FireFox проверяет сертификат сервера? Неужели открытый ключ CA и в клиентском сертификате есть?
Свободно он зашел или нет — надо смотреть по упомянутому логу auth.txt. В принципе он мог использовать уже установленное ранее SSL-соединение, даже если сам сертификат уже удален (все ключи есть в контексте соединения — служебной структуре браузера, заполняемой во время подключения).
Да, диагностика там намного менее подробна, чем в WinSock. Коды ошибок Eserv получает по SSL_get_error, и все варианты перечислены здесь:
Это верно. И в принципе понятно. Сервер вроде-как отрабатывает нормально. А вызывает подозрение именно клиент. Складывается впечатление, что FF не проверяет сертификат сервера.
FF перезапускал. И в auth.txt имеется запись что соединение свежее.
Кстати. Интересный момент. IE не может зайти даже с установленными сертификатами. EServ выдает ошибку 5 в auth.txt
В FF и других браузерах при работе по httpS результат проверки всегда хорошо виден — по иконке "замОк", цвету адресной строки и т.п. Там можно щелкнуть мышкой и посмотреть всю информацию о сертификате сервера.
Клиентскими? Или CA?
FF, Opera, IE открывают без каких-либо вопросов.
Ну да. подозрения подтвердились, когда щелкнул на замочек. "Информация о владельце этого веб-сайта отсутствует". А ведь в FF установлены и клиентский и CA. FF проигнорировал проблемы с CA. Явно я что-то накосячил с генерацией сертификатов. Но FF этот факт игнорирует. IE ни с клиентским, ни с CA, ни с обоими одновременно не работает. Опера, клиентский сертификат вообще не принимает.
Честно говоря, возникают сомнения, проверяет-ли EServ подленность клиентского сертификата (т.е. подпись CA на клиентском Серт-те)
А ведь ни тот и ни другой не имеют отношения к владельцу сайта
"Информация о владельце этого веб-сайта отсутствует" пишется о сертификатах большинства сайтов, в т.ч. известных (см. например
Т.е. такая надпись не говорит о том, что браузер не принял сертификат. Если браузер не хочет принимать сертификат, то он пишет что-нибудь паническое, и соединение не устанавливает. Вот например,
Браузер и не должен "принимать" клиентский сертификат. Браузер проверяет серверный сертификат. Потом, если сервер требует идентификацию клиента (если есть флажок "1" в нашем случае), он запрашивает у клиента клиентский сертификат. При этом он выдает клиенту список CA, чью подпись на сертификате он согласен принять (этот список он берет в нашем случае из server.pem). Если в браузере есть клиентский сертификат (и соответствующий закрытый ключ, т.е. "персональный сертификат" или "личный сертификат"), подписанный CA из списка, то браузер выводит пользователю окошко со списком клиентских сертификатов и предложнием представиться этим сертификатом. Либо автоматически передает подходящий сертификат, если ранее в этой сессии он уже выбирался. (т.е. это работает как с http-паролями) Если в списке сертификатов браузера подходящего персонального сертификата не установлено (у FF и IE списки разные, т.е. нужно устанавливать в каждый из браузеров), то он представиться не может. Дальнейшее поведение сервера зависит от второго флага (SSL_VERIFY_FAIL_IF_NO_PEER_CERT=2) — он либо согласится работать с неизвестным клиентом, либо не согласится (как было на деле, был ли клиентский сертификат — вы видите в логе auth.txt).
Если в auth.txt есть информация из клиентского сертификата, значит всё проверено. Если клиентский сертификат был, но подпись на нем не соответствует доверенным CA, то Eserv даже не узнает (от openssl), что этот сертификат был, соответственно и в логе это поле будет пусто.
По моему мы немного друг-друга не поняли. Я имел ввиду вот что:
Как я понимаю, SSL сессию с флагом Verify=3:
- Клиент коннектится к серверу
- Клиент отправляет серверу свой Личный сертификат (назовем его client.pem), в котором содержится открытый ключ клиента (назовем его client.key). Соответственно этот Личный сертификат подписан с помощью закрытого ключа CA (CApriv.key) и сертификата CA (CA.pem). В моем случае это CA собственного изготовления.
- Сервер проверяет сертификат Client.pem с помощью CA.pem. Если подпись CA на client.key верна, сервер считает, что клиент прошел проверку.
- Сервер отсылает свой, серверный сертификат (server.pem) также подписанный с помощью того-же CA.
- Клиент, с помощью CA.pem проверяет подпись в Server.pem. Если она верна, клиент считает, что соединился именно с тем сервером, с которым хотел. И это не "человек в середине".
Другие проверки, типа соответствие URL адреса и др. реквизитов сертификата я не упомянул т.к. они не столь актуальны сейчас.
Исходя из этого алгоритма. У сервера и у клиента, помимо собственных сертификатов, должен быть установлен сертификат CA (CA.pem)Так вот, смущало меня то, что FF и без CA.pem совершенно спокойно заходил на сайт. Без всяких нервных сообщений. Но причину отсутствия ругани я нашел. FF без CA.pem ругаться стал. Но если принять исключение, все равно пускает. Но это вопрос уже не к Вам. Но если Вы что-то знаете на этоу тему...
Когда я говорил про то, что Опера не принимает клиентский сертификат, я имел ввиду, что он не устанавливается в Оперу.
Кстати. Попробовал заменить EServ stunnel'ом. Собственно, эффект тот-же. FF работает нормально, IE 8 отказывается работать. Ну с Оперой понятно. Даже сертификат установить не дает.
Тут, в общем-то вопросы не к Вам т.к. проблема явно не в EServ'е. Но если есть какие-нибудь зацепки, то буду рад информации, ссылочкам на тему и т.п.
Да, так и должно быть. Точнее, быть может как угодно, как решат разработчики клиентского софта, но для удобства они обычно решают действовать именно так — предупредить клиента о том, что "что-то здесь не так" (сертификат истёк, домен не тот, издатель неизвестен, флаги использования не те, и т.д.), но предоставить ему возможность проигнорировать все предупреждения и работать-таки с этим сервером (т.к. техническая-то возможность работать с таким сервером есть, даже если все политики нарушены).
Если сертификат создавался не в Опере, то его надо туда импортировать через "Безопасность/Управление сертификатами/Импорт", экспортировав предварительно оттуда, где он у вас есть (из FF, например). Общепринятый формат для переноса персональных сертификатов (с закрытым ключем) — PKCS#12 (*.pfx или, что то же самое, *.p12).
IE8 отказывается как именно? Что пишет на странице отказа, и что предлагает делать?
Да. Собственно оно и понятно. Меня изначально настораживало отсутствие ругани FF. Я и добивался, чтобы он ругался, если чего-то не хватает. Но вот то, что он дает потом зайти — это не радует.
IE я победил. Вот его поведение мне понравилось. Он пускает только если импортируешь и клиентский и CA. А FF пускает без CA т.е. даже без возможности проверить сертификат. Хоть и ругается.
Сам собой. Сначала сгенерировал его с помощью OpenSSL, подписал с помощью CA, конвертнул в PKCS#12. FF принимает, IE тоже. А Opera почему-то нет. Беде дальше экспериментировать.
Молча или таки ругается на что-то?
Говорит что-то типа "Не удалось импортировать сертификат"
Сейчас потестировал — у меня Opera 10.63 нормально импортировала мои pfx'ы, включая экспортированный из FF webmoney'вый сертификат для авторизации на light.webmoney.ru. Да и раньше проблем с сертификатами в Опере не замечал, если не считать несовместимой с IE кодировки кириллицы.
Новые клиентские сертификаты можно и прямо в Опере создавать. Специально восстановил сейчас старый триальный кейген для Eserv —
FF не ругается на ваш самодельный сертификат при отсутствии CA в списке доверенных, т.к. возможно вы уже однажды добавили его в исключения безопасности. Попробуйте заменить основной сертификат (с ключем) в server.pem.
Да.Это я уже решил. Удалил исключение из FF.
ред: 30.03.2011 10:29
Вписал в OnThreadConnect.rules.txt строку SSL_CLIENT GetCertEmail SetLoggedUser
Собственно, thunderbird все равно ругается, что серверу пароль не понравился. А пароль я в TB и не пытался вписывать
А ругань будет, конечно — протокол POP3 в принципе предусматривает авторизацию, поэтому логин и пароль передаются TB независимо от ваших правок в конфиге сервера. Даже если это получится обойти на стороне клиента, нужны дополнительные правки в конфиге, потому что почтовый ящик сейчас устанавливается только при выполнении явной протокольной авторизации.
Авторизация по сертификату возможна там, где она не обязательна по устройству протокола — в SMTP, HTTP, Socks.
Насчет SMTP еще не могу точно сказать, получилось или нет. Надо потестить. А вот pop3 говорит invalid user:Pass, что свидетельствует о ругани сервера.
Переменная User принимает нужное значение, но это не спасает "Отца русской демократии"
SMTP тоже не работает. Даже GetCertEmail пустую строку выдает. Ну и соответственно User остается пустым.
А в SMTP, похоже, не связалось что-то.
ред: 30.03.2011 18:17
Спасибо. Работу протоколов я представляю. И понимаю почему TB меня пароль просит ввести. Но мне не понятно, вот чего. Если в данной сессии аутентификация уже выполнена по сертификату (или по IP, MAC), то почему-бы не выдавать OK на любой пароль от клиента? Ведь по сути пароль уже не нужен. Пользователь определен по сертификату (IP, MAC и т.п.) А сервер выдает invalid:Pass... Не логично... И соответственно вся эта аутентификация по сертификатам (также как по IP и MAC) становится не актуальной. Все равно нужен пароль...
А что? И где?
Для этого в файле acIMAP\conf\pop\OnLogin.rules.txt замените строку "LOGIN" на
Если SSL_CLIENT пуст, значит клиент не предъявил сертификат или предъявил негодный (при данных опциях).
И на любой логин?
Я не знаю, реализовано ли это где-нибудь. Теоретически возможно, конечно — но тогда вам нужна очень строгая проверка клиентских сертификатов. Я ведь могу сгенерировать сертификат с вашим адресом, подписать его имеющимся EservRootCA и таким образом получить доступ к вашей почте.
А что до SMTP — давайте смотреть в DATA\log\stat\201103auth.txt за соответствующий момент времени. По идее — раз для POP SSL включается, то и для SMTP должен, разницы быть не должно при одинаковых настройках.
Она проводится, если включена опция SslVerifyClient=2 (клиентский сертификат проверяется на предмет подписанности той цепочкой сертификатов, которые положены в server.pem вместе с сертификатом и ключем сервера).
Закрытого ключа от EservRootCA у вас наверное нет ( ?
ред: 05.04.2011 15:27
Вписал в OnThreadConnect.rules строчку
А в OnLogin.rules вписал
Собственно файлики прилагаю.
Файл:
Файл:
Из второго файла:
Нужен ли там "0="? Ведь тогда при совпадении логина получим FALSE...
В конец OnThreadConnect.rules добавил SSL_CLIENT GetCertEmail SetLoggedUser
В OnLogin добавил UID @ 0= | LOGIN
Далее эксперимент с TB.
Отсылаю себе письмо и пытаюсь принять. Если в поле "Имя пользователя" стоит логин и домен (например Ivanov@domain.ru), то все работает как надо. А вот если без домена (просто Ivanov), TB не ругается, но и ничего не принимает. При обычной авторизации такой проблемы не возникает.
Собственно, я нашел решение. Но оно годится только для одного домена. А у меня в будущем их будет больше одного.
ред: 05.04.2011 17:05